Curse

DarkCloudInc · Jan 28, 2007, 07:27 PM // 19:27

Since the last update allowed for screenshots in jpeg, I thought I didn't have to use the macro in photoshop to convert all the screenshots to jpeg.

But when I started taking screenshots after the update, it still made them into bmp.

Anyone know hwo to get it to do it in jpeg?

Tachyon · Jan 28, 2007, 07:54 PM // 19:54

Consider it a blessing! The quality of jpegs is apalling when compared to bmp's and if you're going to be doing any editing at all in photoshop then bmp will be a better choice all around.

That said, mine still outputs in bmp because I added the -bmp switch to the command line. You didn't add that yourself did you and forget about it?

DarkCloudInc · Jan 28, 2007, 08:25 PM // 20:25

no switches were put on the shortcut, so it still outputs bmps.

Wrath Of Dragons · Jan 28, 2007, 08:48 PM // 20:48

http://www.guildwarsguru.com/forum/s...php?t=10109309

see if that helps

Ayamari · Jan 28, 2007, 08:58 PM // 20:58

Quote:

Originally Posted by Azagoth

The quality of jpegs is apalling when compared to bmp's and if you're going to be doing any editing at all in photoshop then bmp will be a better choice all around.

Yeah right.

Tachyon · Jan 28, 2007, 09:13 PM // 21:13

Quote:

Originally Posted by Ayamari

Yeah right.

Yeah! Jpeg uses lossy compression techniques whereas bmp isn't compressed at all. Personally I prefer to use the 24bit PNG format for my image editing, but no games I can think of actually output in that particular format.

DarkCloudInc · Jan 28, 2007, 09:23 PM // 21:23

as I said, the bmp switch isn't at the end of the "target:" line in the shortcut, so its still outputting bmp screenshots.

Ayamari · Jan 29, 2007, 05:03 PM // 17:03

Quote:

Originally Posted by Azagoth

Yeah! Jpeg uses lossy compression techniques whereas bmp isn't compressed at all. Personally I prefer to use the 24bit PNG format for my image editing, but no games I can think of actually output in that particular format.

Ok then tell me the difference (except the bmp being 3 times larger.) between a 24 bit bmp and the same image in jpg. Original was bmp,wich I then saved in photoshop at quality setting 12 into jpg. ;|

Edit: A trained eye like mine will spot a small difference, but it's nothing that justifices the 3x file size. >_>

aeroclown · Jan 29, 2007, 05:53 PM // 17:53

I would like to help clarify lossless compression versus NO compression
(uncompressed files), and offer this brief tutorial to help. I am doing
this because this is very important stuff to understand for some. Keep
in mind there are varying opinions on these formats as well as how and
when they should be used.

The most important thing to come away with after this brief tutorial is
that - at the end of the day - the result (the picture) is EXACTLY the
same using uncompressed video or LossLESS compression. LossLESS
compression means compressing the DATA that has resulted from the
digitization process, and the compression process used in LossLESS
compression does not alter the data and therefore there is no alteration
to the image. So what is the advantage of LossLESS compression - why not
just keep it uncompressed as some have suggested? Easy - the same
quality content can be stored in much less space. Is there any reason
NOT to use lossLESS compression? No, there really isn't. Is it used for
other things? Yes - you use it all the time on your computer - as
mentioned in an earlier email - .zip and "stuffit" files are lossLESS
compressed file types, and there are MANY others. Is LossLESS
compression the same as LOSSY compression - like MPEG 2 or 4. NO they
are totally different - LOSSY compression DOES change image quality.
LOSSY compression is NOT used for data storage for most applications for
the simple reason that what you put in is NOT what you get out -
therefore it has limited utility. Is lossLESS compression new? No,
lossLESS compression is a standard aspect of data management and storage
in computer systems and has been around - probably from the beginning. LossLESS
compression saves valuable storage space AND retains the data in the same condition
it was in before compression. LOSSY compression is the
"new" one, and lossy compression is really only used for a few
applications like for pictures, audio, streaming, video transmission,
and similar applications where some are willing to tolerate quality loss
for a severe reduction in storage space and/or bandwidth. Though personally,
I am one of those people that just cannot tolerate the quality loss and insist that
compression of any kind only be done on the final render. If you compress data using
a lossy compression to early your final results are usually horrifically mangled and
difficult to work with. In most computer science applications, however, lossy compression has little utility.

Let's look at a few examples which will hopefully clarify these issues.
I want to say up front that the examples I am giving right now are NOT
precisely how video is compressed, but I am explaining it this way
because it is a visual metaphor that is easy to understand.

Let's examine up-close and personal a few lines of video. Any video -
PAL, NTSC, HD - it does not matter. Let us decide to look at the top 2
lines of video, and let us say that the top 2 lines are the color red.
If you look REAL close at a TV picture you will see red, green, and blue
dots - and for our example now let us assume that only the red dots are
illuminated in the two lines we are discussing. For the moment let us
break up the analog horizontal line of video into discrete locations and
let us call them pixels. And let us say that there are several hundred
of them across the screen - in fact let's say that each single cluster
of red, green, and blue dots is one pixel. That would mean that one
could pick any given cluster and light up any combination of red, green,
and blue at any location along the line to give us a wide variety of
colors at that specific location. Let us also think for the moment that
we have 256 levels of brightness for each color in the cluster (red,
green, and blue). So for the first pixel located on the first line
(expressed in terms of x which is horizontal axis and y which is the
vertical axis)... location 1,1 (first row first column - x,y) the values
for color are Red 255, Green 0, Blue 0. Since any location COULD be any
combination of those 3 colors and brightness values there are actually
about 16 million possibilities. You could for instance have Red 255,
Green 0, Blue 255 which would give you a magenta color. Now back to our
original 2 lines of video.

One way that we could express or store all the information for those 2
lines would be to do the following in columnar form.

X Location Y Location Red Value Green Value Blue
Value
1 1 255 0 0
2 1 255 0 0
3 1 255 0 0
and on and on and on until we have documented every color value for
every pixel location on each line

Well that is pretty wasteful isn't it. Look at all that data you have to
carry around. Let's figure out some ways to reduce that waste WITHOUT
changing the information at all. You probably already have figured out
that you don't need to carry around all those 0's for Green and Blue for
each location. Heck - why not just keep the red values. Say something
like:

X Location Y Location Red Value Green Value Blue
Value
1 1 255 0 0
2 1 255 No Change yet
3 1 255 Nothing yet - I'll let
you know
4 1 255
.... .... 255

What I have done here is just reduce by 2/3 the amount of color
information that I have to carry around. Pretty good lossless
compression just by using common sense. And we can do more too - much
more. How about saying - I am not going to tell you the colors for every
location UNLESS there is a change - after all why be so redundant? And
there isn't a change until the first pixel location on the third line -
the first two lines are all red - so -

X Location Y Location Red Value Green Value Blue
Value
1 1 255 0 0 - and
don't change the color values UNTIL I give you a location where the
values change.
1 3 210 100 19
2 3 110 20 129

I have now compressed 2 lines of information into the space formerly
required for only 1 pixel. Pretty clever, and I have not changed a thing
in the picture. I am not carrying around data that has no utility; I
only carry the information if there is a change.

I can even go further and only carry the changes to the information
itself -

X Location Y Location Red Value Green Value Blue
Value
1 1 255 0 0
1 +2 -45 +100 +19
+1 0 -100 -80 +110

Can I go further - you bet. I can say -

1,1 - 1,3 255

Said out loud - from location 1,1 to location 1,3 - red value 255 no
other color information or 0 (which is black)

In that way I have compressed several THOUSAND numbers into only 7, and
I have not changed the picture at all. Uncompressed or Lossless
compressed the picture is identical. We have not changed how often we
sample the picture locations or the data rate - we have just saved tons
of space. This is the type of thing that mathematicians have great fun
with, and there are many techniques that can be used to squeeze every little bit
into the smallest space possible.

In the "real" world in video we digitize the waveform or analog signal
and don't save actually pixel locations because the original line was
analog in the first place (there really aren't any discrete pixel
locations in an analog signal) and doing it this way is actually
compression as well - but the point is the same. We are not changing the
picture at all by compression of this type.

In fact, a discussion of the digitization process itself may be more
nitty gritty but really more relevant in terms of what you are
preserving in the file in the first place. In the audio world there are
many vendors that sell digitizers and one can actually do a comparison
between different vendors and the results of their products. Unhappily
video is not quite that far along yet - most people rely on the vendor
stating what they do without much testing or comparison. I suspect that
as the technology moves along there will be more product to compare and
testing approaches to compare it with. Most of the video industry is
focused on lossy compression like MPEG 2 and 4, and most of the test
equipment and encoders (aka compressors) are in this market segment. Though
again as I said earlier personally, I am one of those people that just cannot
tolerate the quality loss and insist that compression of any kind only be done
on the final render if at all. If you compress data using a lossy compression to early
your final results are usually horrifically mangled and difficult to work with. Lossless
compression is used mostly in high end applications like graphics production where
lossy compression is unacceptable for quality output. I suspect/hope that this will
change as more and more people start saving their content in lossless compressed formats.

You may wonder what the "gotcha's" are. As they say - "there is no free
lunch"... Well there are a few. While the compression techniques
illustrated above do a very good job with a solid area of color, they
would do poorly with a picture of a complex nature; say a picture where
there are constant changes in color. In fact it is possible for the
compressed file using a technique outlined above to be LARGER then the
uncompressed file. Fortunately most software is smart enough to see
this, and will use whatever is the most effective in terms of storage
space though sometimes at a cost. Most algorithms use several techniques to get
the file into the smallest space possible. Another gotcha is that it takes processing
power and time to compress and uncompress the files - as compared to doing very
little for raw uncompressed data. The good news here is that this type of compression
can be "burned into silicon" and the resulting hardware can be VERY fast - compressing
an entire frame in the time of a vertical interval (real time).